home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 11426 < prev    next >
Encoding:
Text File  |  1996-08-05  |  4.2 KB  |  148 lines
  1. Newsgroups: comp.object,comp.lang.eiffel,comp.lang.c++,comp.lang.beta,comp.lang.java,comp.lang.sather
  2. Path: newsfeed.acns.nwu.edu!ftpbox!mothost!schbbs!news
  3. From: shang@corp.mot.com (David L. Shang)
  4. Subject: What Should An Exception Handling Do?
  5. Reply-To: shang@corp.mot.com
  6. Organization: MOTOROLA 
  7. Date: Thu, 14 Mar 1996 15:56:41 GMT
  8. Message-ID: <1996Mar14.155641.4299@schbbs.mot.com>
  9. Sender: news@schbbs.mot.com (SCHBBS News Account)
  10. Nntp-Posting-Host: 129.188.128.126
  11.  
  12.  
  13. I cross post this message to languages that have exception
  14. handling, and am asking for better ideas in exception handling.
  15.  
  16. I like Ole Madsen's definition in his book:
  17.  
  18.    An exception is a class of computational states that requires
  19.    an extraordinary computation.
  20.  
  21. It is not possible to classify whether state is expected or not;
  22. but this state do need some extraordinary attention.
  23.  
  24. We have two cases:
  25.  
  26. 1. Such extraordinary attention required in a function is
  27.    dependent on the user's choice, and an implementor can
  28.    do nothing with it;
  29.  
  30. 2. Such extraordinary attention can be handled by the
  31.    implementor directly; 
  32.  
  33. I belive that the first case is the most important; and the second
  34. case does not necessarily to use exception handling. And the first
  35. case is rather easy to be handled for recovery.
  36.  
  37. But, most exception handling mechanisms focus on the second case,
  38. which makes exception handling very complicated for recovery. (C++
  39. even gives up recovery.)
  40.  
  41. Also, exception handling helps in improving the code readability
  42. in the first case, but may unecessarily complicate the code
  43. structure in the secon case.
  44.  
  45. Let us consider a simple example: a function to put an item in a
  46. collection.
  47.  
  48. We consider the second case first. Suppose that the put function
  49. should expand when a full "exception" is raised. The implemetor
  50. will expand the collection without allowing the user's decision.
  51. If we use exception handling, the code will read like this (not
  52. in any language):
  53.  
  54.    class collection
  55.    {
  56.        function put (item: any)
  57.        {
  58.        if (full) throw COLLECTION_FULL; // raise an exception
  59.        put the item in
  60.        }
  61.        catch  // 
  62.        {
  63.        when COLLECTION_FULL: expand(); retry;
  64.        }
  65.    }
  66.  
  67. The code structure is unecessarily more complicated than:
  68.  
  69.   class collection
  70.    {
  71.        function put (item: any)
  72.        {
  73.        if (full) expand();
  74.        put the item in
  75.        }
  76.    }
  77.  
  78. Now, we consider the second case: the put function should ask
  79. user's decision. Then exception is a good mechanism to handle
  80. this situition (in Transframe):
  81.  
  82.    class collection
  83.    {
  84.        function put (item: any) exception (COLLECTION_FULL)
  85.        {
  86.        if (full) throw COLLECTION_FULL; // raise an exception
  87.        put the item in
  88.        }
  89.    }
  90.  
  91. Now user should decide what to do:
  92.  
  93.   c: collection();  // create a collection;
  94.   try (c.put("a_string"))
  95.   {
  96.      when COLLECTION_FULL: c.expand(); retry;
  97.   };
  98.  
  99. This structure is more readable than the one in which exception
  100. handling is not used. Let us have a comparison on the useage of
  101. file's open operation.
  102.  
  103. With exception handling, user can write code:
  104.  
  105.   f: file of Image();  // create a blank file reference;
  106.   image: Image =
  107.      try (f.open(name))
  108.      {
  109.          when FILE_NOT_FOUND:
  110.           if (name!=system_name) name:=system_name;
  111.           else name:= my_window.PopupOpenFileDialog();
  112.           if (name) retry; else return null;
  113.          when FILE_WRONG_TYPE:
  114.           name:= my_window.PopupOpenFileDialog();
  115.           if (name) retry; else return null;
  116.      };
  117.  
  118. Without expcetion handling, user has to write code like:
  119.  
  120.   f: file of Image();  // create a blank file reference;
  121.   image: Image;
  122.   err_info: FileErrorInfo;
  123.   image = f.open(name);
  124.   while (!image)
  125.   {
  126.      err_info:= f.GetFileErrorInfo();
  127.      switch (err_info)
  128.      {
  129.          case FILE_NOT_FOUND:
  130.           if (name!=system_name) name:=system_name;
  131.           else name:= my_window.PopupOpenFileDialog();
  132.           if (name) image = f.open(name);;
  133.           break;
  134.          case FILE_WRONG_TYPE:
  135.           name:= my_window.PopupOpenFileDialog();
  136.           if (name) image = f.open(name);
  137.           break;
  138.      }
  139.      if (!name) break
  140.   };
  141.  
  142. Lots of flow-control statements are involved, and the structure
  143. of the code becomes complicated, error-prone, and unreadable.
  144.  
  145. David Shang
  146.  
  147.  
  148.